home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Gold Medal Software 2
/
Gold Medal Software Volume 2 (Gold Medal) (1994).iso
/
comms
/
gt1800_1.arj
/
README.18
< prev
next >
Wrap
Text File
|
1993-07-22
|
68KB
|
1,336 lines
+--------------------------------------------------------------------+
| GT POWER 18.00 Notes |
| Paul Meiners |
+--------------------------------------------------------------------+
P&M Software Co.
3104 E. Camelback Rd.
#503
Phoenix, AZ 85016
Voice (602) 897-9557
Modem (602) 897-9549
7/5/93
If you are converting from a previous version of GT POWER, it would be
an excellent idea to backup your hard drive(s) before beginning. Care
has been taken and considerable testing has been done, but mistakes
are always possible when upgrading software from one release level to
the next.
Most of the control files are the same as were present in 17.xx. The
only conversion that must be done is the building of the "joins". This
is done by running the SYSOP.EXE program and selecting option #12.
When asked about rebuilding the "joins", answer 'Y' and the needed files
will be created automatically. On any subsequent run of SYSOP.EXE, it
won't be necessary to build the "joins".
NOTE: Be sure to take a careful look at the SYSOP.BBS file, it contains
many new and modified entries. If you are in any doubt, replace
your old SYSOP.BBS with the new file, then customize to taste.
WARNING: All major program files have been updated... including GT.WIN,
SYSOP.BBS, SYSOP.EXE, DELREN.EXE, in addition to the GT EXE and OVL
files. Please be sure the new GT.WIN file is installed, it is most
important!
1. Many new log entries are now made. In addition to all the new log
entries, detailed logging is now an option. One can enable the
detailed logging by changing the value of item #24 under Alt-I setup
to the DETAIL setting.
Among other things, detailed logs will show each message base a
caller has referenced and how it was referenced, i.e. mail check,
read global, regular reading or QWK access. Also, each file area
the caller entered will be logged. In addition, strange or un-
expected result codes from the modem, like VOICE, ERROR, NO DIAL
TONE, etc. will be logged. Finally, busies will also be logged.
2. The FAX Token is found in the SYSOP.BBS on line number 355. It
should be changed to a value appropriate for your modem, if you
want GT to passoff to a backend FAX program. If GT is waiting for
a call in host mode and detects a modem result code containing the
FAX Token, then GT will execute the GT_FAX.BAT. I've been told that
the ZyXel modems can be set to CLASS=6 and then handle this sort of
passoff from a frontend BBS program. I am not familiar with the
ZyXel modems or their software, so I am counting on Lane Smith, and
other GT Beta Testers who own ZyXel modems, to help everyone with
their setup.
3. Files that are uploaded without any description are now added to the
FILES.BBS, just like files with descriptions. But the description
will read: No description available. This has been done so that
it is easier to keep track of files that are uploaded without
description.
4. The following main menu commands are available from the file
tagging menu (while viewing lists of files, of course):
(L) .... List directory.
(W) .... Whereis file.
(C) .... Change file area.
(I) .... New file inquiry.
(LU) .... List uploads.
(D) .... Download.
(U) .... Upload.
These keys are semi-hot, as is the (N) key, by the way. A semi-hot
key, in this case, can be pressed anywhere on the screen, the
caller doesn't have to return to the prompt line. As soon as GT
"sees" the first keystroke for one of these commands, the cursor
will automatically jump to the prompt line and wait for a carriage
return... or the (U) in the (LU) command.
In effect, the caller doesn't need to return to the main menu to
execute these commands.
5. The new Scrollback Buffer defaults to 200 lines, but may be
configured via Alt-I, option #9, to between 0 and 400 lines.
The [Ctrl-Up] key combination triggers viewing of the buffer. Once
viewing has begun, [Esc] must be pressed to return to normal
operations. During viewing of the scrollback buffer, the [Home],
[End], [PgUp] and [PgDn] keys navigate thru the text. The [Up] and
[Down] arrow keys can also be used to move up and down 1 line at a
time.
To save memory, for those in tight memory situations, the /NS
command line switch can be used to totally disable the Scrollback
Buffer.
6. Freebie download areas can now be specified. This is done by
adding a modifier before the pathname in the GTDIR.BBS file.
The modifier is '', the "paragraph" character, ASCII 20. Here
is an example:
.z GENERAL General File Areas
z C:\GT\OBJ Home GT directory
E C:\GT\C General file area
Notice the 2nd line, it has the '' character just in front
of the pathname... in effect making any file downloaded from
that area a "freebie"... i.e. not included in the caller's
download statistics.
Because of these "freebie" files, it has been necessary to revamp
the files database, to include a new flag to mark "freebie" files.
So make sure you run the new FILES_DB.EXE so that the new "freebie"
areas work properly.
Also a freebie list is being introduced. The freebie list should
contain no more than 200 filenames without extensions. The list
is in a file named FREEBIE.BBS. Here is an example:
gt1706_1
gt1706_2
pcfile1
pcfile2
pcwrt_1
pcwrt_2
When a caller is about to be charged for downloading, the
freebie list is checked, without regard to extension, to see
if the filename is on the list, if so, the download statistics are
not updated. The filenames should begin in column 1 of each
line of the file.
7. MS-Windows: GT automatically detects when it is running in the "DOS
Box" of MS-Windows and tries to return unused time to the operating
system. The method used to return time to MS-Windows should have
an added benefit for users of OS/2 also. Time is released via
software interrupt 0x2F, function 0x16, subfunction 0x80, and this
interrupt is supported by both MS-Windows and OS/2.
This release also includes GTPOWER.PIF and GTPOWER.ICO, which
can easily be installed in your "Non-Windows" group by using the
program managers "drag 'n drop" feature. If you have any trouble
getting the icon to setup properly, the change properties option
of the program manager's file menu can do the trick.
If you are using a high speed modem under MS-Windows, you will
soon find out that your 16550A uart looks like a 16450 to GT. This
is caused by the fact that the standard COMM.DRV that comes with
MS-Windows doesn't support the FIFO mode for DOS apps.
But you can increase the buffer that MS-Windows allocates... and
that will help. In the [386Enh] section of the MS-Windows SYSTEM.INI
file should include the following entries:
COM1Buffer=512
COM2Buffer=512
The default size used by MS-Windows is 128, which simply isn't
enough. I am not sure what the maximum value is, but 512 works
great for me.
Because GT now releases excess time back to the operating system,
the priority level assigned to GT thru its PIF file should be high.
I have used 1000 as the background priority and 2000 as the fore-
ground priority. I am currently running netmail under MS-Windows
too, using a priority of 5000 for both foreground and background.
It seems to work smoothly.
Final note... it is important that both GT and the netmail programs
run in a window with locked memory... it takes too long to reload
a comm program from the swap file <GRIN>.
A new version of the DELAY.EXE program is also included... it also
gives up excess time to the operating system. This makes it much
more friendly to the MS-Windows environment.
8. A new command line option, /W, is now available. If this option is
specified on LAN systems, GT will perform the whereis style lookup
to find files for download. Normally, this rather time consuming
search is not done on LANs.
9. GT now supports the Caller ID feature. To make this option work,
the BBS must be using a modem that supports Caller ID reporting,
such as the SupraFAXmodem. The modem must be conditioned to report
the Caller ID information and the phone company must have the
feature enabled on your line. The Supra uses the following to
enable Caller ID reporting:
AT#CID=1
GT requires the Caller ID report to be in ASCII text format.
GT looks for the Caller ID information to be reported between RING
result codes, so /R2 should be used with GT, if you want the Caller
ID reported. That is, GT should be setup to answer on the 2nd ring.
To distinguish the Caller ID info from other result codes, GT looks
for a particular token to be on each line of the Caller ID report,
the Supra modem puts " = " on each line, as follows:
RING
DATE = 0419
TIME = 1726
NMBR = 6028979549
NAME = MEINERS
RING
This is captured text from testing I was doing with my Supra.
I was calling my voice line from my BBS line.
RING
DATE = 0408
TIME = 1325
NMBR = O
MESG = 08014F
RING
This is more captured text that shows what is reported when Caller
ID info isn't available... perhaps because the caller has it
blocked, or the call is coming LD from an area that doesn't supply
the required info.
If your modem uses a different token, instead of the " = ", line
354 of the SYSOP.BBS file needs to be altered to reflect the
proper token for usage with your modem. I've been told that ": "
works with some modems, such as the ZyXel modems.
The Caller ID information is recorded in two places: (a) the
GT.LOG, and (b) a file named CALLER.ID. The CALLER.ID file is
provided for usage by 3rd party programs in the logon process:
GTLOGON.BAT and GTNLOGON.BAT. The information is recorded as
reported by the modem.
10. The caller's access level is now logged with his password and caller
number.
11. The DSZ log handling has been improved so that is now considers
a transfer of type 'S' to be a download (instead of an upload, as
it did before <GRIN>).
12. The (V)ersion command now displays the local date and time, in addition
to the GT POWER id.
13. A "global" option has been added to the (W)hereis command, allowing
the caller to limit searches to the current directory. Also, the
search headers are now single spaced and the "More?" prompt only
comes up after a "find" has been made... thus the caller doesn't
have to press CR for screen after screen of meaningless search
headers... this speeds the process quite a bit.
14. With the advent of CDROM, a difficult problem for GT has been
handling ever larger numbers of files in the files database. GT
17.06 could handle 32,000 files. This wasn't enough! So the
limitation has been raised to 320,000 files! GT achieves this by
splitting the database into 5 separate files, each with a maximum of
64,000 files per database.
The old database files were named: FILES.CTL and FILES.IDX. These
files should now be deleted and the new FILES_DB.EXE program run to
create a new database. The new files will be named:
FILES_0.CTL FILES_0.IDX
FILES_1.CTL FILES_1.IDX
FILES_2.CTL FILES_2.IDX
FILES_3.CTL FILES_3.IDX
FILES_4.CTL FILES_4.IDX
The files database *MUST* be recreated in this fashion prior to
installing the new GT release. It is recommended that you specify
the approximate number of files in the database, for example:
FILES_DB 6000
This informs the program of the approximate size of the database
in files. There can be more, of course, but it takes time to
expand the database, so it is better on the high side!
A command line switch, /CD, has been added to help speed successive
database builds for the same CDROM. The database records for the
CDROMs are read from the old database, rather than from the CD
itself. Speeding succeeding database builds by at least an order
of magnitude.
If you have a new CDROM or on the initial build with the new program,
the /CD switch _must not_ be used.
15. GT now incorporates its own archive viewer, using the command [AV]
from the BBS main menu. The archive viewer can be invoked while
looking thru the listings of files on the board, in much the same
way that files are tagged for download, just position the cursor
to the desired file and press 'v', the archive viewer will be
invoked on the indicated file, and the caller will be given the
option of adding the file to the download list (after looking over
the contents). GT will create some temporary files and directories
to handle this function:
GT$ARCV.nnn .... temp file, holds the table of contents
for the archive currently being viewed.
ARCV$nnn ....... temp directory to hold files extracted for
viewing.
'nnn' is a number between 000 and 999.
These are created under the GTPATH and are erased when the caller
logs off.
The archive viewer has the ability to view nested archives... nested
up to 999 levels deep. And the caller will be given the option of
downloading elements from within the archive... in case he doesn't
need the whole thing! In that case, the archive viewer will extract
the desired files and recompress them for downloading.
16. A new batch file will now be executed, GT_PIGGY.BAT. This batch
file will be executed after every download and upload session.
(if the GT_VSCAN.BAT isn't executed).
That is, if the GT_VSCAN.BAT is executed after uploads, the
GT_PIGGY.BAT won't be executed, so its logic should be included
in the GT_VSCAN.BAT (if you have one). Of course, the GT_VSCAN.BAT
isn't done after downloads, so the 'piggy' batch file will be
executed after *ALL* download sessions.
GT will create a file to be processed by the 'piggy' batch file,
it is called GT_XMIT.LST and will be placed in the GTPATH. The
format of this file, when the 'piggy' batch file is executed, is
as follows:
0000000352 G Sam Spade
0000000117 0 0 0 C:\BBS\AREA1\CBGREET.BBS
0000001424 1 0 1 C:\UPLOADS\PURSUIT.RTE
0000019742 0 1 0 F:\MSDOS\DIR1\UNREGECO.COM
The first line contains a header that identifies the caller:
Col 1-10 ..... seek address for the caller's record in the
USER.CTL file.
11 ..... blank
12 ..... the caller's access level.
13 ..... blank
14-43 ..... the caller's name.
The remaining lines in the file define the transfer session that
just finished:
Col 1-10 ..... the size of the file in bytes.
11 ..... blank
12 ..... rx/tx flag: 0=download, 1=upload, 2=aborted
3=QWK mail, 4=DIZ compatible upload.
13 ..... blank
14 ..... CDROM flag: 0=normal disk, 1=CDROM disk
15 ..... blank
16 ..... Freebie flag: 0=normal, 1=freebie
17 ..... blank
18-92 ..... complete pathname of the file.
This hook for a potential up/down ratio system. It is my
hope that some 3rd party author will grab this and run with the
ball.
17. Doors may now have screen files optionally associated with them.
For example: GTDOOR1.BAT could have GTDOOR1.BBS (or CBS). These
screens are displayed prior to the caller entering the selected
door.
18. When "DETAIL" logging is enabled, GT will now log all messages that
are entered by callers... and give the name of the person to whom
the message is addressed.
19. When searching for the bulletins listed on GTBMENU.BBS, GT
will now search the default file path (as before), followed
by the GTPATH and the BBS/CBS path. So the bulletins can now
be moved out of the default file path!
20. A new command has been added to the main menu, (UG) upload and
goodbye. The (UG) command will only work properly, if all the
uploads contain a "diz" file. If any of the uploaded file don't
contain a "diz" file, then the caller will be prompted for a
description of the file, thus counteracting the automatic (G)oodbye
function.
21. An successful uploader is now given a two minute grace period after
entering the upload descriptions, so that a time bank withdrawal may
be made. This avoids the abrupt disconnections seen in the past.
But may cause a schedule overrun... please allow more than a two
minute start window on scheduled events, to insure they are
performed.
22. After chats invoked during logoff, GT will now re-ask the caller if
he wishes to logoff after the chat is finished.
23. A log of recent callers is now kept. The RECENT.BBS log is
recorded in reverse order, i.e. the latest callers are at the
top of the list and the oldest callers are at the end of the list.
The first line of the RECENT.BBS must specify the number of callers
you want kept on the list... it defaults to the most recent 50
callers. Here is what the first line should look like:
;50
The ';' must be in the first column of the line... the number
following is the desired length of the list, in this case 50
callers will be recorded in LIFO order.
On LAN systems, the RECENT.BBS is kept in the LAN Path, but
the work file, RC$TMP00, is placed in the GTPATH directory.
The '00' is the pid number of the updating node. This temporary
work file will normally be removed automatically, but in the
case of a system crash it may remain cataloged. It may be erased,
or left alone with no harm done.
If you wish to make the RECENT.BBS visible to your callers, you
will need to make it available via a bulletin or other screen.
The ^F, file include feature, is useful for this purpose.
24. It is now possible to place GT .OVL and other files outside of the
GTPATH, if they are in the DOS PATH someplace. For example, if you
are running a RAM disk and want three files to be in it... and the
RAM disk is the pathname F:\RAM\, then prior to executing GT copy
the GT OVL, the GT.WIN and the SYSOP.BBS to F:\RAM. Then in your
AUTOEXEC.BAT file make sure that F:\RAM is in the DOS PATH statement.
Finally, insure that no other copies of these files are in the DOS
PATH someplace... because there is no guarantee on the search order,
i.e. the wrong copies might be found.
For files that are normally in the BBS/CBS directory, the directory
search order is now: the OVL directory, the GTPATH directory and
the BBS/CBS directory. In the case discussed in the paragraph above,
the OVL directory would be the RAM disk.
Finally, if the OVL file is present in the GTPATH, then that would
override the DOS PATH. So make sure that the OVL file is only in
the RAM disk on the DOS PATH, and _not_ in the GTPATH directory!
25. Some more new command line options are now available:
/AI ..... Causes the program to issue the ATA| string to the
modem immediately and take the call in host mode.
This is useful if you have a frontend program that
can pass on a RING to GT... such as some of the newer
fax programs, that can detect distinctive ringing.
/BV ..... Force BIOS Video = TRUE. This parameter overrides
any other BIOS Video setting in the GT.CNF file.
Hopefully, this will be useful to users with
speech synthesizers.
/QR ..... Allow output from PKZIP to be echoed to the caller
during QWK mail packet creation.
/W ...... Perform "whereis" style lookups on LAN based systems.
Normally this isn't done, due to excessive delays that
might occur... normally, only the files database is
used to find files
26. A CDROM copy to harddisk routine is now optional. If the sysop
wishes to take advantage of this routine, then he should MKDIR the
GT$CDROM directory in the GTPATH. GT will detect the subdirectory
and perform the copy from CDROM to this subdirectory and do the
download from there. If the GT$CDROM directory is not present,
then the copy is omitted and the download is done direct from the
CDROM.
Remember, the CDROM is identified by the ",CD" switch in the
GTDIR.BBS. If the ",CD" switch is not setup properly in the
GTDIR.BBS, then the files database will be built correctly and
the copy to harddisk won't be performed.
27. New commands for questionnaires:
[%LG,text]
The "text" is written to the GT.LOG.
[%LG,%10]
The answer to question # 10 is written to the GT.LOG.
[%LG,%PR]
The answer to the previous question is written to the GT.LOG.
[%JB,GENERAL]
This commands allows the sysop to join a caller to a message
board.
Where "GENERAL" is the board name from the board/group
header line, '.' in column 1, in the GTMDIR.BBS file.
28. The NB permission is now available. Access levels marked by
the NB permission in the GTPASSWD.BBS file are not allowed the
bulletin menu. They do, however, read the logon bulletins when
they call the system.
29. The file tagging system has been improved somewhat, i.e. it now
looks into the files database, before accessing the disk drive.
Which should work better on CDROM drives.
30. Attempted names are now logged, so that you can see who callers
might think they want to be <GRIN>.
31. GT has been changed so that terminal mode users can now get a
[Tab] list when uploading with external protocols that have the
"Batch" switch = 'Y' in the external protocol table under Alt-I.
32. A new internal protocol has been added: Super MegaLink.
This protocol has been assigned the (M) menu character used by
MegaLink in the past. The old MegaLink has been given the (A) menu
character. Please check to make sure these assignments don't
conflict with your external protocol setup. Changes may be
necessary to the external protocol table and the PROTOCOL.BBS file.
One of the improvements in Super MegaLink is that it now
uses a quick/auto start signature... similar to that used by Zmodem.
But it is not the same as the Zmodem signature, obviously.
Super Megalink is designed to get the most out of the new high
speed modems (v.32bis and the upcoming v.fast). It uses variable
size blocks, so that blocks may be as short as 128 bytes, on noisy
lines, or as high as 16k bytes on clean lines. The baud rate in
use also effects the block size, as the program will choose the
best fit for the situation. For example, at 2400 baud, error
retries would take a very long time using a 16k byte block.
There is a price for these efficiency improvements tho... the
Super MegaLink protocol isn't suitable for usage on packet switched
networks, such as Telenet's PC Pursuit.
33. It has been a long time since space was allocated in the USER.CTL
file to record the default file transfer protocol for each caller...
now, GT will make use of that field. GT will automatically
record the protocol used by the caller and use it by default until
the caller changes the selection via the (Y)our info routine.
A new ^U variable for screens is now available: Z = the user's
default protocol.
The (Y)our info routine offers callers a choice of NONE for their
default protocol. Callers with a default protocol of NONE will
have to specify their protocol choice for each file transfer
session, as it was before there was a default protocol. To get the
selection set to NONE, the caller must actually type the word "none".
34. The Time Bank has been given a (R)edeposit option. So that callers
can put back excess time that they had previously withdrawn during
the current session.
This new feature is probably redundant, even before I get the code
released, as GT will now automatically redeposit time bank credits
that were previously withdrawn and not used, when the caller logs
off.
35. GT now adds uploads immediately to the files database... so
callers can tag them for download in the normal manner. This
does away with the need for frequent rebuilds of the database.
Even with this though, I would recommend that the database be
rebuilt on a periodic basis---at least once or twice a month.
Of course, if you rename files or move them about, you will
still need to run FILES_DB.EXE to rebuild the database.
36. As uploads are received, GT will record their descriptions in
an additional place (in addition to the normal FILES.BBS). That
new place will be a special file, created in the GTPATH or in the
LAN path (if running on a LAN), named UPLOADS.BBS. This file will
be a LIFO list, that is it will record the uploads in the reverse
order in which they are uploaded. So that the newest uploads will
appear at the top of the file, the oldest will appear at the bottom
of the file.
IMPORTANT: the UPLOADS.BBS must be created, originally, by the sysop
in the GTPATH (or in the LAN Path on networks). GT will
not originally create this file, but will update it, once
created by the sysop.
When you look at this file, it will appear much like a regular
FILES.BBS, but it _IS NOT_. The first difference is seen on the
very first line of the file. The first line contains a semi-colon
followed by a number, like this:
;200
The semi-colon should appear in the very first position on the line.
The number tells GT how many files you wish to keep listed in the
UPLOADS.BBS. When the file has more than the desired number, GT
will drop off the oldest files, in order to keep the right number
on the list.
The 2nd difference between the UPLOADS.BBS and a regular FILES.BBS
is the presence of a security specifier for _EACH_ file entry. That
specifier appears before the filename... for example:
A FOO.BAR 1024 01-20-93 01-15-93 from: Paul Meiners
| This is the description
| for FOO.BAR. It is a tasty file.
=J CREAM.PUF 10240 01-19-93 01-15-93 from: John Doe
| This is the description of CREAM.PUF
| It will be seen only by 'J' level callers.
The 'A' and the '=' should be in the first position of the line.
Because of the security placed on each file in UPLOADS.BBS, regular
comments in this file should be placed only as a header at the top
of the file... because comment lines do not have security associated
with them (everyone will see the comments, but the associated files
may not be visible). The description lines are associated with their
files, and have the same security assigned to them (unlike comments).
It is anticipated that the sysop might want to manually add files to
the UPLOADS.BBS... but normally, automatic maintenance of the file
will be performed by GT.
A new main menu command has been implemented to list these uploads
for the caller... the LU command, Latest Uploads. The LU command
checks the security level for each file individually, before listing
it for the caller, insuring that only files downloadable by the
caller are shown.
As new uploads are received, GT must create a temporary file in
the GTPATH (even on LAN systems), so that the UPLOADS.BBS file
may be updated. If the system crashes during an update cycle,
the temporary file may remain leftover in the GTPATH. It may
be erased---be sure you have a good UPLOADS.BBS file before
erasing the temporary file, as it may be your only backup. The
filename is GT$TMP00 (where the '00' is the pid number for the
node where the file is located. GT attempts to handle conflicts
created by simultaneous uploads on multiple nodes at the same time,
but it is possible that things will get rather slow, if very many
nodes process upload descriptions at the very same moment.
37. If the caller pages the sysop, without receiving an answer, the
caller is given a chance to send a private message to the sysop.
Also, when the caller logs off, the caller is offerred the chance
to send a private message to the sysop before GT executes the
logoff batch file. This should encourage callers to communicate
via message with the sysop (it is thought that confused callers
may not be able to leave messages asking for help otherwise).
38. The format of the display shown during screen blanking has been
improved. The current mode, host or terminal, is indicated, along
with the call count and the crash count, if in host mode.
39. The default value for GTVBUF (what GT uses if you don't give a
value) has been raised to 140k.
40. Some sysops have mentioned that GT was too quick in dropping
callers when the DCD signal is lost. Now, item #13 under Alt-I
has been expanded, so that a time interval, in seconds, can be
specified, between DCD loss and the disconnect of the caller.
I have experimented, and found high values to be a nuisance---so I
have mine set to 1 second. If you have a flaky modem or loose cable,
perhaps higher values will be beneficial... but I don't think so...
I advise that a very low value be used for this parameter.
41. The default message base and default file area are now configurable
on an access level basis. Here is an example of the change needed
in the GTPASSWD.BBS file to implement this feature:
C1 [1:00,1000,2:00] CLASS UP,DN,MS,PR,PW
| FILE=c:\gt\c MSG=d:\trade
Please note that the 'C1' begins in the first position of the
line, and that the '|' is indented with blanks (not tab characters)
to the left of it. Any access level definition in the GTPASSWD.BBS
file can have a '|' entry following it. On the '|' line, either of
the area definitions may be included or left off... in which case,
GT assumes the default area from Alt-I, #26, for the omitted area.
The entries on the '|' line are not in a fixed position. But blanks
must not be embedded within the definitions.
The 'FILE=' specification lists the default file area for the related
access level, and the 'MSG=' specification lists the default message
base.
42. A new permission, RA, has been added to the GTPASSWD.BBS file.
Callers who have an access level containing the 'RA' permission are
in bad shape <GRIN>. First, they are not permitted the bulletin
menu. Second, when they get to the main menu, they are shown two
files: RA_HELP.BBS and RA_HELPx.BBS. And then they are led to
leave a private message for the sysop... which they can decline,
of course. In any case, they are logged off immediately afterwards.
This new permission is called "Restricted Access". One step above
being banned...
The 'x' in the filename RA_HELPx.BBS is the bullet number assigned
to the caller's access level. For example, if the caller was 'E1'
from the GTPASSWD.BBS file, i.e. access level E and bullet number 1,
then they would see the RA_HELP1.BBS after viewing the RA_HELP.BBS.
Both of these files are optional, and GT will not complain if they
are missing.
43. While GT is waiting for a call, GT will reassert the DTR signal
approximately every 5 minutes... as some systems have reported
that the DTR signal drops for unexpected reasons (usually some
interaction with 3rd party software, such as DV, a LAN or DVDOOR).
44. The SeaLink protocol has been improved. The window size has been
made proportionate to the baud rate in use. Higher baud rates will
get bigger window sizes. This was done in such a way that it is
backward compatible with older implementations. For very high
baud rates, window sizes of over 70 blocks are now possible.
45. The presence of a duplicate file in a batch upload, using
internal protocols, should no longer inhibit the system
from collecting file descriptions for those files success-
fully uploaded.
46. FILES.BBS may now span multiple directories. This is done
by including a ";PATH=" entry in the FILES.BBS where the
directory break is located. For example:
GT1706_1.ARJ GT Power main program documentation
GT1706_2.ARJ GT Power main program - Std. Version
;PATH=c:\gtbbs\general
PCFILE1.ARJ Part 1 of the PC-File database package.
PCFILE2.ARJ Part 2 of the PC-File database package.
This pattern may be repeated over and over again within a
single FILES.BBS type file. This feature is most useful for
CDROMs, where numerous small directories, containing only
a few archives, may be present on the CD.
47. The ^F, file include command, now works within FILES.BBS
type files. This is a handy feature for use with CDROMs
because small listings can be "pasted" together using the
^F entry. The ^F feature can be combined with the ";PATH="
feature, described above, to aid in the combination of
smaller directories into a single larger area.
The ^F character must be placed in column 1 of the line in
which it appears, followed immediately by the full pathname
of the file to be included. Like this:
^Fc:\cdrom\general.dir
Naturally, the ^F symbol is used to represent the actual
Ctrl-F character. In the example given above, the file
"c:\cdrom\general.dir" would be displayed and processed as
if it were part of the FILES.BBS.
48. Personal bulletins are now possible. These files, if you
create them, are named according to the caller's "Caller Number"
in the caller's user record. To aid sysops in determining
the proper caller number, this number is now recorded in the
GT.LOG file, whenever the caller logs onto the system. If
necessary, the SYSOP.EXE program may be used to lookup caller
numbers. Here is an example:
4872.BBS
If this file was located in the GTPATH or BBS/CBS Path, then
it would be displayed for caller number 4872 whenever he calls
the system. When composing the filename, the sysop should
suppress leading zeros. For example:
0052.BBS is incorrect.
52.BBS is the right way.
It is possible to have CBS versions of these files, but it
will work properly if _only_ the CBS version is available.
And care must be taken to make sure that regular numbered
bulletins don't get confused with personal bulletins, i.e.
a file named '1' would be a numbered bulletin, and '1.BBS'
would be a personal bulletin, and '1.CBS' would be a total
confusion... but it would show up as a personal bulletin _and_
a numbered bulletin. To avoid this confusion, it would be best
to avoid the .CBS extension... or barring that, place the numbered
bulletin files in the default file directory and the personal
bulletins in the GTPATH directory, then there will be no confusion
between the two, even if CBS files are used.
49. New script commands have been added, as follows:
PROPER ----- convert normal text into first character
capitalized text. For example:
v1 proper "john Brown"
produces "John Brown" in the variable V1.
QWK -------- process QWK format mail packets. The following
variations are available:
QWK export "Your Name" bbsid c:\gt\foo.bar
QWK import "Your Name" c:\gt\foo.bar
QWK prepack "John Brown" c:\gt\foo.bar
QWK reply "John Brown" c:\gt\foo.bar
export --- create a REP packet suitable for upload
to the BBS identified by "bbsid". An
.IMP file needs to be located in GTPATH
for this to function. "Your Name" is the
name of an authorized person on your board.
c:\gt\foo.bar is the full pathname of the
output file... usually using the REP
extension.
import --- convert an incoming QWK packet from another
BBS into your GT message bases. An appro-
priate .IMP file needs to be located in the
GTPATH for this to function. "Your Name" is
the name of an authorized person on your
board. c:\gt\foo.bar is the full pathname
of the incoming file... usually using the
QWK extension.
prepack -- create a QWK packet for the caller who is
named "John Brown" and store it in the file
c:\gt\foo.bar.
reply ---- read in the REP packet from "John Brown" and
store the messages into your GT message bases.
c:\gt\foo.bar is the full pathname of the
incoming file... usually using the REP
extension.
Here is a sample script for using the new QWK script commands:
CLEAR
WRITELN "Packing REP for GTHOME..."
WRITELN " "
QWK EXPORT "Paul Meiners" GTHOME C:\GT\UP\GTHOME.REP
CLEAR
WRITELN "Dialing the Programmer's Workshop -West!"
NAME "the Programmer's Workshop -West!"
DIAL 897-9549 WITH 50 REDIALS
WAIT FOR "[y/n]"
SENDLN "N"
WAIT FOR "name:"
SENDLN "Paul;Meiners;y;xxxxxxxx;y;qk;r"
WAIT FOR "number:"
SENDLN "5"
WAIT FOR "name:"
SENDLN "GTHOME.REP"
WAIT FOR "abort."
ZMODEM XMIT GTHOME.REP
TWAIT 1000
FLUSH
SENDLN
WAIT 400 FOR "help):"
SENDLN "qk;d"
WAIT 500 FOR "abort."
ZMODEM RECV *.*
WRITELN
WRITELN "Waiting for host to finish up..."
TWAIT 7000
WRITELN
WRITELN "Disconnecting!"
SENDLN "H"
TWAIT 2000
HANG-UP
LOG "Good Transfer with GTHOME"
END
WRITELN
WRITELN "Unpacking the QWK packet from GTHOME"
WRITELN
QWK IMPORT "Paul Meiners" C:\GT\DOWN\GTHOME.QWK
WRITELN
WRITELN "End of script processing."
WRITELN
50. Help menus have been added to the following:
CK_HELP.BBS ----- help menu for the mail check command.
RG_HELP.BBS ----- help menu for the read global command.
QK_HELP.BBS ----- help menu for the QWK mail command.
ME_HELP.BBS ----- help menu for the message edit sub-menu.
MSG_HELP.BBS ---- help menu for the regular read mail command.
RA_HELP.BBS ----- help menu for RA access callers.
RA_HELPx.BBS ---- help menu for RA access callers with the 'x'
access level.
TAG_HELP.BBS ---- help menu for file tagging.
Except for the RA_HELP screens, which are presented automatically,
the caller can invoke these menus, from the applicable submenus
by using either (H)elp or (?). Examples are included in the
release package.
51. In the absence of EMS memory, GT is now capable of using
XMS memory for overlay management. But please note, the
usage of an XMS memory manager is required. Such as HIMEM,
QEMM, QRAM or 386/MAX, etc.
52. The DIZ file for upload descriptions is now supported. GT
will extract and use the 1st DIZ file within an uploaded
ARC, ZIP, ARJ or LZH for the upload description... informing
the caller that the DIZ file supplied the description.
53. The dialing directory now remembers the cursor position
beyond an external event. It used to reset to the start
of the dialing directory, but no longer.
54. Capitalization rules for names have changed. Some some callers
will find themselves as new callers (the user file is case
sensitive).
Old way New way
--------- ---------
O'donnel ----> O'Donnel
Mcdowell ----> McDowell
MacDonald ----> MacDonald
Not all names beginning with "Mac" will be handled correctly,
as not all "Mac" names are Scottish or Irish.
55. Capture mode is now persistent, i.e. it resumes without loss after
returning from an external event, such as a door or file transfer.
Be careful, very large captures are now possible, since the capture
buffer is not automatically closed.
56. The "no download" time prior to an event has been shortened, from
25 minutes + pre-event wait, to 5 minutes + pre-event wait.
57. The way that users join message boards has been changed. Each
message board will now have a .CTL file associated with it in the
"joins" subdirectory. The "joins" subdirectory will be created
under the GTPATH directory, like this:
C:\GT\JOINS
The control file for each board will be named according to the
board name in the GTMDIR.BBS. In the example above, if the
board/group was named "GENERAL", then the join file would be:
C:\GT\JOINS\GENERAL.CTL
Assuming C:\GT is the GTPATH.
On a LAN, the "joins" directory will be placed in the LAN Path.
58. A new command, UB, to allow callers to unjoin a message board.
When first installing the new version of GT POWER, one should
run option 12 of the SYSOP.EXE program and answer 'Y' when asked
if you want to rebuild these board control files. Option 12 of
SYSOP.EXE should be used periodically to cleanup the join control
files.
59. A record of files kept offline is now kept in the "files database",
so that the caller is not fooled by files stored offline. If an
offline file is tagged, GT will explain that the file is "OFFLINE".
60. The auto-download signature of HS/Link is now recognized. When
the terminal mode of GT receives the following string of characters:
ASCII Characters: H S * ^B
Hex values: 0x48 0x53 0x2A 0x02
The external protocol assigned to the 'H' menu character will
automatically be started in receive mode. This works very similar
to the existing auto-download using Zmodem, when the external
protocol assigned to the 'Z' menu character is automatically
started.
61. GT now supports QWK Mail. The QWK format is widely used by
offline mail readers and for networking.
GT implements the QWK format as described in the document,
"QWK Mail Packet File Layout" by Patrick Y. Lee, version 1.3,
July 6, 1992. Some things have not been implemented (yet),
while some features implemented are unique to GT -- for example
the way GT implements its tagline via the GTQUOTES.BBS file.
To setup the QWK mail feature, several things must be done.
a. A file named QWKSKEL.BBS must be created and placed into
the GTPATH or LAN PATH directories. A sample is shown
below:
The P&M Test System
Phoenix, AZ
(602) 897-9557
<owner name>, Sysop
<serial number>,GTHOME
<packet date>,<packet time>
<caller name>
0
<message count>
<conference count>
<conference list>
GTWELCOM.BBS
GTBULLET.BBS
GTBYE.BBS
This is a skeleton of the QWK CONTROL.DAT file. The items
within <...> should be left _as is_, GT will fill in the required
information. The <...> are there as placeholders. Line 1 has
the name of the BBS. Line 2 has the city-state of the BBS.
Line 3 has the phone number of the BBS. All these things should
be filled in, as appropriate. On line 5, there appears the
BBSID after the ','. This should be 8 characters that identify
your board -- the characters should be suitable for usage as
a filename, so avoid unnecessary control or special characters.
On the last 3 lines of this file, you will find the names of
the "HELLO" file, the "NEWS" file and the "LOGOFF" file. The
sysop may vary the names that appear here, as appropriate for
his setup.
QWK mail cannot be processed, if this file is incorrectly setup
or not setup at all.
b. A file named GTQUOTES.BBS should be available in the GTPATH or
the LAN PATH. GT will use this file to pull up quotes for
inclusion on the tagline in the reply messages. Here is an
example:
0000000000~
The gods play games with men as balls. -Titus Maccius Platus
He was a wise man who invented God. -Plato
Plato is a bore. -Nietzsche
The information on the first line should not normally be changed,
it provides GT with information on the previously used quotation
so that new ones can be used in their turn. If you make a lot of
changes to this file, you should probably zero out the line, as
showed above. But since this line acts like a "placeholder", the
format requires 10 zeros followed by a '~' character.
There should be at least a couple of quotations in this file.
Each quotation is limited to 64 characters, if you wish it to
appear normally in the message. There may be any number of
quotations in the file -- as you have disk available. GT will
use them sequentially, and return to the top of the file, after
all have been used.
c. The SYSOP.BBS has numerous new lines pertaining to the handling
of QWK mail. They are near the end of the file. For example,
at line number 314 you will find the following line:
"M=200,C=50/100,TM=2000,K=1000"
This line specifies, in order:
M= the maximum number of messages per conference to be
put into the QWK packet.
C= the maximum number of conferences with messages/total
to be put into the QWK packet. The example above shows
50/100, which means up to 50 conferences with messages,
up to a maximum of 100 conferences scanned.
TM= the maximum number of messages to put into the QWK
packet.
K= the maximum size of the MESSAGES.DAT file in kilobytes.
This is prior to compression! In the example above,
1000k is allowed, which would probably compress down
to a packet of around 500k... roughly speaking.
The K, M and TM values on this line are not used directly, but
are changed proportionately according to the caller's DCE baud
rate. If the caller is at 9600 baud, then the values will be
used as is. If the caller is below 9600 baud, the values will
be lowered proportionately. For example, if the caller is at
2400 baud, the values will be divided by 4, at 1200 baud they
will be divided by 8, etc. If the caller is above 9600 baud,
these values will be raised proportionately. For example, if
the caller is at 19200, the values will be doubled. At 14,400
the values will be multiplied by 1.5.
Another important entry in SYSOP.BBS for QWK mail is line number
310. This line contains the command used to compress the QWK
packet. It comes setup for use with PKZIP, as that is the most
common compression program used. But you may change this...
depending on the capabilities of your callers. Be sure, if you
change it, to use the "move" option... note the "-m" used with
PKZIP.
d. QWK mail processing requires authorization, a caller must either
be the sysop or have the 'QK' permission listed for the access
level in use. In addition, any caller that uploads a REP packet
must have 'UL' or the upload permission.
e. QWK transactions now have their own Time Bank values. The TB=
permission has been expanded to allow for two more values, as
follows:
uk uf dk df me mr mk qk rp dl wl
TB=01/02/03/04/03/01/50/01/01:060/600
The new values are shown above under the 'qk' and 'rp' headings.
They represent the number of credits to be deposited per 100
messages processed. The 'qk' value is for D/L'ed messages,
and the 'rp' value is for U/L'ed messages.
f. The 'QK' main menu command brings up a sub-menu for the caller.
From the sub-menu, the caller can choose to download a QWK or
upload a REP. Network commands may also be executed from the
QK menu. If a QWK download is selected, all joined areas are
scanned and processed, up to the limits described above.
Following the packing, the download is started immediately...
using the protocol of the callers choice. If the caller refuses
to select a protocol, Zmodem is selected by default.
The a QWK sub-menu is called GTQWK.BBS (which may also have a
.CBS version). It is like any other screen file.
g. The sysop has a command to himself, 'RP', which unpacks a
'REP' packet that has been placed in the QWK directory. This
is a sysop only command.
The QWK directory is named GT$QWK00, the '00' is the pid number,
so there may be up to 32 such directories. They are placed under
the GTPATH directory. GT places QWK packets here after they have
been created. And rep packets are placed here for GT to unpack.
The QWK directory may be made available to callers via the
GTDIR.BBS or GTUDIR.BBS, but that is optional and up to the
local sysop.
The QWK work directory can now be specified via an environment
variable as follows:
set GT$QWKnn=f:\foobar\qwktemp
The environment variable is customized for each pid, i.e. 'nn'
represents the pid number, or '00' for single node systems.
The pathname given must be completely specified, and normally
should be different on each pid, to avoid share violations.
This should allow sysops to place the work directory onto a RAM
disk, on the LAN server, or on the workstations... wherever the
sysop finds most efficient.
h. REP packets are uploaded by callers in the normal manner.
Instead of asking for a description, GT will automatically
recognize the REP packet, move it to the QWK directory and
unpack it, while the caller is watching. ZIP, ARJ and ARC
are supported achivers for REP packets.
i. The GT QWK feature supports these three control commands:
ADD, DROP and RESET.
As far as I can tell, these commands operate virtually in
a transparent mode with the offline readers I've tried.
The commands are put as the topic of a message, addressed
to "GTQWK", in the particular conference affected. ADD and
DROP are pretty self-explanatory, RESET means to reset the
"last read" pointer to zero. The RESET command can take a
non-zero argument, i.e. RESET 200, in which case, GT QWK would
reset the message pointer to message #200.
j. The GTMDIR.BBS must be updated to include the following
information for any conference you wish to make available
via QWK mail. Not all conferences need be available!
The new information:
a. Conference number. 0 to 65534, excluding conference
numbers 8192 - 8447, which are unusable.
b. Conference id. Up to 10 characters, no blanks.
Blanks may be included by using the '_', underscore,
character, which GT will convert to a blank.
For example:
.z GENERAL General Board
z ~C:\MAIL,10/Netmail Netmail area
z ^C:\GOSPA,20/Our_Lady The Messages Of Our Lady
z ^D:\IDEAS,30/Beta_Ideas Save Ideas From Beta Testers
Notice that the conference number and id code follow the pathname
with a comma between. And a '/' separates the number and the id.
Any conference without a conference number will be omitted from
the QWK packet processing. And naturally, the normal security
is enforced, so conferences will be skipped automatically, if
they wouldn't normally be seen during normal message processing.
k. Packing QWK mail takes a bunch of memory. So make sure that
you have _at least_ 200k available when GT is loaded. If not,
then adjust the GTVBUF to make more available. REP processing
uses even more memory than packing QWK packets --- so you risk
loss of REP packets if insufficient memory is available. The
more conferences you have, the more memory you need. GT has
no specific limitations on the number of conferences that can
be processed, but it takes about 80 bytes of overhead for
each conference you have in the QWK mail setup. If you had
1,000 conferences in the setup, then that would require an
extra 80k of memory! Over and above your normal memory require-
ments. Which could be as high as 70k for REP processing!
l. To send netmail messages from a QWK packet, simply put
the following as the first line of the messages:
;nm:1/33
Naturally, the ';' would appear in column 1, and the
appropriate net/node number should be used. 1/33 is
my net/node number, used for demonstration purposes.
m. The Net Status, NS, permission has been added. This permission
works with a new BBS file, QWKTRASH.BBS. When GT receives an
REP packet or an imported QWK packet, the message sender's name
will be matched against the names found in the QWKTRASH.BBS file.
If a match is made, the message will be discarded. If the
QWKTRASH.BBS file contains a line that reads:
=STRICT
with the '=' beginning in the first position of the line, then
all messages must be from the caller himself, unless the caller
has Net Status permission. All names in the QWKTRASH.BBS file
must begin in the first position of each line.
To recap, any message, which has a sender's name match an entry
in the QWKTRASH.BBS file, will be discarded. If the QWKTRASH.BBS
file has a '=STRICT' entry, then only messages from the caller
himself will be accepted, unless the caller has the Net Status
permission.
Finally, only 64 lines may be put into the QWKTRASH.BBS file,
extra lines are simply ignored.
n. QWK networking is also being introduced. Consider the case of
a caller who downloads a QWK packet from your board, normally
it is fed into an offline reader and only that single individual
can read and reply to messages. But what if the caller runs
a BBS... if the caller uses GT, then the QWK bag can be imported
into the message bases on that BBS, via the main menu (IM)
command or the (I) command on the QWK menu. To use these
commands, import or export, requires the IM or EX permission
in the GTPASSWD.BBS file (the sysop gets these implicitly).
To accomplish an import or export operation, requires that the
appropriate .IMP file be available in the GTPATH directory. Here
if the format:
Filename: GTHOME.IMP
--------------------
Import Local
Conf# Conf#
------ -----
0052 -> 1052 ;Trading Post
0057 -> 1200 ;Shareware
The information starts in column 1, it is indented here for
readability only. Only lines that begin with a number are
processed, all others are considered commentary. The first
column of numbers (may be 5 digits, if required) represents
the incoming conference numbers, the column of numbers following
the arrow, "->", are your local conference numbers. The incoming
QWK packet may have many many conferences, but only the ones
listed in the .IMP file will be imported (or exported).
The filename you choose for the .IMP file is very important,
because the main part of the name, before the '.', must match
the BBSID of the incoming QWK packet. The incoming packet
has the BBSID stored internally in the CONTROL.DAT file.
When the replies are exported, GT will ask for the BBSID to
use with the export operation, it must match-up with an .IMP
filename, as GT will only export the files listed in an .IMP
file.
Here is a graphic representation of what is going on:
+--------------+
| Host BBS | BBSID = GTHOME
+--------------+
/ \
+-------------+ +-------------+
| D/L QWK PKT | | U/L REP PKT |
+-------------+ +-------------+
| |
| /|\
\|/ |
=============|==========================|============
| |
| |
| |
+-----------------+ +-----------------+
| Import QWK PKT | | Export REP PKT |
+-----------------+ +-----------------+
\ /
+--------------+
| Client BBS |
+--------------+
GTHOME.IMP file required on
the client system. Filename
must match BBSID of QWK host.
GTHOME, in this example.
When importing or exporting qwk/rep packets, GT will scan
the related .IMP file and pickup any line beginning with 'TAG='
as the tagline to be added to the messages, instead of getting
entries from the quotes file. The information following the '='
will be used, as is, on the tagline (of course, GT will still
prepend its signature)... which will include 'GTnet', instead
of the plain 'GT' put on regular QWK messages. The information
after the TAG= will be truncated to fit, if necessary. I think
there is room for 63 characters...
Please note, for those having trouble with .IMP file formatting,
the conference numbers _must_ begin in column 1 of each line
where they appear. Do not indent them with white space. I have
seen several examples of folks using IMP files with the
conference numbers indented up to 10 or 15 spaces... and this
is incorrect format.
o. The old message pointers for each QWK downloader are
stored in a subdirectory called QWKSAVE under the GTPATH,
or LAN Path on LAN systems.
The QWKSAVE subdirectory will now save PTR files for each
caller, so that the message pointers can be quickly and
easily recovered, should something happen to the previously
downloaded QWK packet. This is done via the (E) command
from the QWK menu. The pointer files are deleted automatically
as soon as the caller uploads a REP packet, or whenever the
next QWK packet is downloaded.
p. Redirection of the PKZIP output, when creating a QWK packet, is
optional via a GT command line argument: /QR. Without the /QR,
GT will inhibit the redirection... with the /QR, the output of
PKZIP will be redirected to the remote caller. Thus some systems
that can't handle DOS redirection to the COM port are now allowed
for.
The End.
Regards,
Paul Meiners
7-10-93
